HW#3 --- last modified February 06 2019 04:12:12..

Solution set.

Due date: Apr 11

Files to be submitted:
  Hw3.zip

Purpose: To write an application that uses databases. To do project development using a version control system.

Related Course Outcomes:

The main course outcomes covered by this assignment are:

CLO3 -- Write server-side scripts that process HTML forms.

CLO4 -- Write client-side scripts that validate HTML forms.

CLO5 -- Develop and deploy web applications that involve components, web services, and databases.

Specification:

For this homework I want you to create an image rating website. Before we get into the specifics of this site let me first say how I want your project organized. You should submit a zip of the git repository for your homework in Hw3.zip. Your project should be written using namespace. You are allowed to create variables and array, objects, in the namespace cool_name_for_your_group\hw3 and subnamespaces thereof. Your project directory structure should look like:

.git -- this has all the stuff git uses to maintain the repository
index.php -- entry point into your project
issue.txt or issues.jpg - info about the issues you created for each team mate to work on while building this project
src
 |-configs -- should have a Config.php class with constants for things like database user, password, host, port, etc.
 |            Basically, it should have anything you think I might need to get your program running on my machine.
 |            It should have a script CreateDB.php which can be run from the command-line to make a good initial
 |            database.
 |-controllers -- should contain all the controller classes you write, one per file
 |-models -- should contain all the model classes you write, one per file
 |-resources -- should contain any resources used by your app such as images
 |-styles -- should have any external stylesheets you need
 |-views -- should contain all the view classes you write, one per file
      |-elements -- should contain all the element classes you write, one per file
      |-helpers -- should contain all the helper classes you write, one per file    

For this project we assume the DBMS being used is MySql. You should make base classes Controller, Model, View, Element, and Helper. The namespaces for these and their subclasses should be respectively: cool_name_for_your_group\hw3\controllers, cool_name_for_your_group\hw3\models, cool_name_for_your_group\hw3\views, cool_name_for_your_group\hw3\views\elements, and cool_name_for_your_group\hw3\views\helpers. Your project should use the Model View Adapter pattern that we have discussed previous. Only controller classes are allowed to directly handle request/form data. A controller can use this information to make database calls to get/set/update info in the database, then choose a view, instantiate it, and call its render method to display a web page back to the requesting browser. Only subclasses of Model are allowed to interact with the database. Controllers should make sure to sanitize and validate user data, for example, using the filter_var and filter_input functions in the March 9 Let's Build Something. The base Model class should have methods for performing the initial connection to the database. Only subclasses of View, Element, and Helper are allowed to render HTML. Subclasses of View are responsible for drawing one complete web page. The base class should have a public abstract method render($data) which is implemented in sub-classes. This method should mainly run in PHP copy mode (not interpreted mode) and contain mainly HTML. You are allowed method calls (no recursion) and if-elseif-else constructs, but no looping. A subclass Element is used to encapsulate a reusable fragment of a webpage (for example, a signin form) which might appear on multiple views. The base class should have a public field $view which is initialized in the base constructor to point to the view the element is currently on. The base Element class should also have an public abstract method render($data). A subclass of Controller is not allowed to directly instantiate a subclass of Element, but a subclass of View can. As with views, elements are allowed method calls and if-elseif-else constructs, but no looping. The render method again should mainly use PHP copy mode to output HTML. Finally, subclasses of Helper are used to output common widgets which may appear on views or elements and may require iterating over data in an array to output. For example, outputting a select tag dropdown with many options coming from a field in $data. Another example might be to output the rows of a table based on an field from $data. The Helper base class should also have an abstract method public abstract method render($data). Only views and elements are allowed to instantiate helpers. The render method of a helper is allowed to use looping.

When a user goes to your site they should be greeted with a page that at the top has the words Image Rating in h1 header within an HTML header tag along with some cool logo. On the right hand side of the page should be a Sign-in/Sign-up link. Beneath this should be a sequence of image items. Each image item should consist of a correctly oriented image, beneath which is a caption, the user who uploaded the image, a rating from 1-5, and a date when the image was uploaded. Before the first three image items, should be an h2 tag with Recent in it. These three items should be the three most recently added images in order from most recent to least. Beneath this should be another h2 tag with Popularity in it. Up to ten image items should be displayed beneath this header. These items should be the most popular uploaded items ranked from most to least popular, ties being broken by recentness with more recent on top.

The Sign-in/Sign-up link should take the user to a different view, in which they can either sign-in or sign-up for an account (which might require yet another view to do). Once the user is signed-in, they should end up back at the original page. You should use a database table USER to keep track of user information. This should have as its primary key a user id. Above any image items and below the header tag should now appear a button to upload an image. This button should take a user to another view where they can upload an image. The only image format that you should allow to be uploaded is jpeg. When the image is uploaded, I want you to try to read the exif data it might contain to find the image orientation. (See exif_read_data). I want you to use the GD and Image Functions and this exif data to make sure the image will draw in the correct orientation and I want you to rescale the image so that it is 500px wide and the w/h ratio is unchanged. You should write uploaded images to the resources folder. The upload form should also allow the user to enter a caption. The filename of the image, the user id of the user who uploaded it, the caption, and the time of upload should be stored in a database table.

When a user submits form data you should use the POST-REDIRECT-GET design pattern so that the back button is not broken. The user should be notified whether the upload was successful and be given a link either to upload another image or a link back to the main page.

If a user is signed in and then the user can rate an image items on the main page. A user should be allowed to rate at most once any image item and can give it a rating from 1 to 5. You can choose how you implement this (no Javascript, jQuery, etc. allowed, however, for this or anything else in this project.) For example, on items the user hasn't voted on yet you might have a drop-down with the numbers 1 to 5. Who has rated what, and information about the average ratings of each image should be stored in at least one database table.

Your team should develop your project using the git version control system. I should see at least three commits from every team member. There should not be more than 200 lines of code different between any pair of commits in the log (except maybe at signoff or merging one team member's code into the master). Your log file should look like it was humanly possible to enter the coded changes between commits. When you develop the project I want you to think ahead and make some preliminary issues that each of your team member are working on. You can use either an issue tracker or create a new group on Yioop for your teammates and view threads as issues, or use a flat issues.txt file to keep track of these. You should include this file, or rss exports from Yioop, or screen shots from your issue tracker in the base folder of the project. You should also have a readme.txt file with your team mates and any info you want me to consider with regard to getting your code running.

This completes the description of the project below is a point breakdown for the various things mentioned above. There are ten line items listed each will graded as either: 1 (completely working or completely following spec), 0.5 (partially working or following spec), or 0 (did not do or highly incomplete).

Point Breakdown